@kaczmarczyck
This PR seems to be wrong.
Do you know why do we need to specify +nightly for cargo even if it is the default toolchain on oss-fuzz ?

When I try to reproduce locally, I don't see a difference between adding nightly or not.

As for the actual problem, I didn't get to the root of it yet.

Oh, or with "wrong", you don't mean for reproducing my bug, but for the failing test?

Oh, or with "wrong", you don't mean for reproducing my bug, but for the failing test?

Indeed, "wrong" means this PR breaks the regular fuzzing builds, even if it fixes the coverage ones

I had a look and it seems that local and docker builds all work, only the GitHub workflow is affected? I'd have to dig deeper into the OSS-Fuzz setup to understand the differences here.

I had a look and it seems that local and docker builds all work, only the GitHub workflow is affected? I'd have to dig deeper into the OSS-Fuzz setup to understand the differences here.

I get the error locally.
Here are my commands

git checkout openskcov
git rebase master
python infra/helper.py build_image opensk --pull
python infra/helper.py build_fuzzers opensk

This gives me the error warning: unknown pass sancov-module, ignoring so we are not using the right cargo version (that is nightly)... But I cannot find why...

Ah I see. For the sancov-module to disappear, you have to specify a nightly from October 2021 onwards. I.e. this works:

--- a/projects/opensk/build.sh
+++ b/projects/opensk/build.sh
@@ -19,7 +19,10 @@ FUZZ_TARGET_OUTPUT_DIR=fuzz/target/x86_64-unknown-linux-gnu/release
 
 build_and_copy() {
   pushd "$1"
-  cargo fuzz build --release --debug-assertions
+  rustup toolchain install nightly-2021-10-01
+  cargo +nightly-2021-10-01 fuzz build --release --debug-assertions
   for f in fuzz/fuzz_targets/*.rs
   do
     cp ${FUZZ_TARGET_OUTPUT_DIR}/$(basename ${f%.*}) $OUT/

but changing the channel to nightly-2021-09-09 doesn't. The most likely change in Rust that causes this behavior should be LLVM 13? OpenSK's toolchain on the checked out branch develop is nightly-2021-03-25, so that might be a difference.

I don't have time to look into LLVM version support in oss-fuzz, but thanks for your help so far!

OpenSK's toolchain on the checked out branch develop is nightly-2021-03-25

Thanks, I think I got the problem.
cf https://rust-lang.github.io/rustup/overrides.html
I rather use RUSTUP_TOOLCHAIN than cargo +nightly

ping @jonathanmetzman @inferno-chromium ?

The build failures just resolved:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36535#c20
Thanks again @catenacyber !